Enterprise servers including relational database servers provide a wealth of capabilities and functions and are correspondingly complex to manage and operate. Managing the servers typically is the task of the administrator, who must consume and assimilate massive quantities of guidance documentation to be even reasonably confident that his/her servers are well-managed. Developers who write applications for the servers must be similarly well-educated.
One of the challenges associated with this self-education process is the sheer mass of information to be considered. For example, vendors publish thousands of pages of documentation designed for administrators and developers, but few administrators and developers have the time to read, much less absorb and remember all that information. Another challenge to be overcome is that the guidance documentation (e.g., “best practice” recommendations) is not consolidated into a single source and may not even be reasonably accessible. Guidance may be provided in vendor documentation or in white papers, but may also be rather inaccessibly stored in the heads of consultants or developers in the development group of software vendors. For example, many times best practice recommendations derive from an understanding of the assumptions under which the product was developed. These assumptions are often known only by the vendor development team. Even supposing a consolidated list of recommendations were available, it is a non-trivial task to verify that a particular installation complies with best practices and to configure the installation to comply with the recommendation.
To make matters worse, the state of the art (what constitutes best practice), evolves. Old knowledge becomes stale, due in part to advances in hardware design, so that best practices recommendations must be updated from time to time, and the servers should be re-evaluated for compliance whenever the best practice recommendations change. Furthermore, different installations or operating environments may want to restrict or customize best practice recommendations. Currently, there is no easy way to do this.
A tangential problem is associated with deprecation, the process by which a feature is gradually phased out of a product. Typically, a vendor who intends to phase out a feature will send messages indicating this intention to users and will suggest a migration alternative or alternatives. Traditionally, it has been hazardous for vendor product teams to deprecate features because even when the message is successfully communicated and migration alternatives are provided, it is difficult for users to assess the impact of the deprecation of a feature and therefore are unprepared when the feature goes away. On the part of the vendor, decisions may be made to deprecate a feature with little awareness of how widespread is the use of the feature. It would be helpful for the software vendor to know the extent of usage of the feature being considered for deprecation. Similarly, it would be helpful for the user to know where the feature being deprecated is used and how widespread is the use and to have advance warning of upgrade problems.
While tools are available that provide recommended database designs (e.g., AllFusion® ERwin Data Modeler) or monitor “the health” of database servers (e.g., SQL Health), no known tools address all the problems noted above. Furthermore, tools provided by third party vendors are not likely to have access to the exact code used in the product on which the tool operates so that the processing that occurs in the tool will not exactly mimic the processing of the product. Similarly, third party vendors are not likely to be able to anticipate or deduce changes based on implementations choices made by the database software vendor.